The present invention relates to an-Internet-based Enterprise Resource Planning (ERP) tool that provides a common hosted environment for multiple users thereof while at the same time permitting individual user customizations for data representations, workflow representations and visual interfaces.
Enterprise resource planning (ERP) software applications have now been in use for several years. Generally, ERP applications handle a wide variety of planning, transaction processing and accounting functions in an integrated manner. While there is no standard definition of an ERP application, it is common for products in this category to handle sales and customer management, forecasting, master production scheduling, material requirements planning (MRP), rough cut capacity planning, production orders, product/material definition, purchasing, supplier management, inventory tracking and financial accounting, i.e., the complete gamut of activities within any business enterprise (hence the term ERP). Many ERP applications also support costing, human resources management, finite capacity scheduling (FCS), quality management and equipment maintenance. The defining characteristic of an ERP application then is its integration of information across many functional areas. In order to provide such integrated solutions, ERP systems tend to rely heavily on databases.
Databases are computer-based record keeping systems. Stated differently, a database is a combination of computer hardware and software that acts together to allow for the storage and retrieval of information (data). Modern databases grew out of older information storage and retrieval systems. For example, early computer-based file systems allowed for record keeping in the form of familiar rows and columns known-as tables. The rows were referred to as records and the columns were known as fields; in order to find a particular piece of information a user browsed through the table and then extracted the needed field or fields from the desired record. So-called xe2x80x9ckeysxe2x80x9d provided more immediate access to information by operating as a sort of index to the data stored in the table.
As the volume of data stored in computer-based systems increased, more flexible storage models (databases) were created. Databases allow for the sharing of data among multiple users through manipulation of user interface tools or command line interfaces that handle the storage, retrieval and modification of the data. Some databases are analytic in nature, providing mainly historical data that is not subject to modification, while others are more operational, in that they allow for managing dynamic bits of data. Furthermore, databases can be segregated by the way in which they model the data stored therein.
Hierarchical databases define relationships among different bits of data according to a hierarchical or tree-like structure. In such databases, a single table acts as a xe2x80x9crootxe2x80x9d, and all other tables in the database somehow depend from that root table. Thus, tables at various levels of the hierarchy may be parents of lower-level child databases, while at the same time themselves being children of some higher-level parent table or the root table. The root table is then defined as a table with no parent tables. In a hierarchical database, a child table may have only one parent, but a parent can have many children.
Network databases are another form of database and allow for child tables to have multiple parents and parent tables to have multiple children. Such a structure can avoid data redundancies that might otherwise exist in hierarchical databases. Unfortunately, network databases can be complex to develop and maintain.
Recently, relational databases have become popular. At the core of the relational database model are the familiar tables (also known as relations) made up of records (rows or tuples) and fields (columns or attributes). Where or how the various tables of a relational database are stored makes no difference. What does matter is that any table can be identified by a unique name and that name can thus be used to locate the table. This different from the hierarchical or network models, which require that users know where in the various trees a particular piece of data is located.
In relational databases, operations that manipulate (i.e., store, retrieve or modify) data do so on the basis of the data values themselves. Thus, if a users wishes to retrieve a row from a particular table, he or she does so by comparing the value stored within a particular column for that row to some search criteria. Also, tables can store not only actual data, they can also be used a means for generating meta-data (data about the table and field names which form the database structure, access privileges to the database, data validation rules, etc.). Thus, relational systems can use operations recursively in order to provide information about the database.
Relational databases are often searched using a so-called structured query language (SQL). SQL provides the structure and idioms needed to query a relational database in a platform-independent fashion. Rather than referring to data as a set of pointers, the SQL provides predefined procedures that allow users to use any value in a table to relate to other tables in a database. Most modem relational databases are SQL databases that are composed of a set of row/column-based tables, indexed by a xe2x80x9cdata dictionaryxe2x80x9d. To access data in the tables, users employ the SQL to navigate the database and produce xe2x80x9cviewsxe2x80x9d based on various search criteria defined in a query. The data dictionary is a catalog maintained by the database that includes a list of all the tables in the database and pointers to their locations in the storage medium. When an SQL query is made, the database looks up the table referred to in the query in the data dictionary in order to know where to go to execute the search. The data dictionary itself, however, cannot be queried directly.
An SQL query is generally made up of several parts. First is a query type, for example SELECT, that defines the type of action requested. Next, the location from which the data is to be retrieved must be specified. Finally, the search criteria which defines the type of information being sought is set forth. In response to the SQL query, the database consults the data dictionary and then accesses the table from which the data has been requested to put together a view. The view is essentially a dynamically generated result table that contains the data retrieved from the table specified in the query according to the user-provided search criteria.
ERP systems that rely on relational (e.g., SQL) databases are common in manufacturing and other environments today. However, one serious drawback of such systems is the need for labor intensive customization at the time such systems are established. For example, for each business in which a particular ERP system is to be established, the underlying tables will have to be uniquely tailored to that business"" work processes. Furthermore, the various user interfaces (e.g., so-called wizards), data entry and retrieval forms, data formats, and workflows will likewise have to be customized to the business. Because modern ERP applications are complex software tools, it is likely that the business purchasing the system will not have the in-house expertise needed to undertake this customization process. Hence, in addition to the capital expended to purchase the ERP application tool itself, the business will have to hire outside contractors to perform the customization and then train the business"" own employees on the use and operation of the system. This represents a significant cost to the business owner and also means that the customized ERP system is not transportable to other end-users.
An additional shortcoming that results from the need for such business-specific customization of existing ERP tools is that such products cannot be easily ported to Web-based (i.e., hosted) environments. To understand why this limitation exists, consider first that many traditional desktop-based applications software packages are today being replaced (or at least supplemented) by Internet-based solutions. One advantage provided by the Internet-based solutions is the availability of immediate upgrades. Thus, users are no longer faced with the task of installing new variants of the software packages they use for word processing, spreadsheet manipulation and other tasks. Instead, by accessing Internet-based forms of these tools, users have immediate access to the very latest versions of the tools and can take advantage of their latest features.
One reason why desktop applications can be readily transported to Internet-based (i.e., hosted) environments is that all users are expected to use the products in the same way. No (or very little) provision is made for user-customization. However, this is not true of the ERP systems described above. Because each business will have specific requirements for their respective data formats (schemas), work flows, user interfaces and other business processes, the simple xe2x80x9cone size fits allxe2x80x9d model of the hosted desktop applications simply does not apply. Accordingly, what is needed is a new model for providing hosted environments for ERP-type software applications.
An operating system or other software application for a computer system provides a hosted environment for one or more customer-specific variations of a data storage and retrieval mechanism that includes one or more base tables to store attributes common to each of the customer-specific variants and one or more spill-over tables to store customer-specific attributes for associated individual ones of the customer-specific variants, the attributes of the base tables and spill-over tables each sharing a common, human readable name referencing scheme. The name referencing scheme may utilize multi-part names for data objects stored in either of the base tables or the spill over tables (or even business rules and/or external data sources) and such names may be used by other applications executing within the hosted environment for creating workflows and/or visual representations of the workflows and/or data input/output forms. Preferably, any such workflows are customized to individual ones of the customer-specific variants and may be created by a workflow engine that segregates transactions to be performed according to processes described by the workflows into asynchronous operations when such transactions cause or initiate actions outside of the hosted environment.
In a further embodiment, a computer-hosted environment provides applications for a number of users. Each application is built on one or more databases having various common aspects across the numerous users and configured to be customized so as to offer each of the numerous users personalized data formats, process formats and/or visual representations for the data formats and/or process formats. The data formats may include data objects referenced by multi-part names, the structure of which is preferably common across logical storage locations within the computer-hosted environment. The process formats may be created to mask indications that actions that have effects outside of the computer-hosted environment are performed asynchronously, and the visual representations of the process formats or the data formats are preferably created so as to show only those transactions that require user action be taken or only those transaction that are permitted to be shown. In some cases, the visual representations may include forms to capture data objects to be stored in the data formats, the forms having corresponding form handlers that utilize the multi-part names to reference the data objects being solicited.
Yet another embodiment provides a data representation scheme for a computer database that includes base tables and spill over tables which allows for customization of the database for multiple users thereof. The data representation scheme includes the use of multi-part names, the structure of which not only allow for references to objects stored in the base tables but also to objects stored in the spill over tables. Thus, a computer-application that includes a workflow engine may be configured to access data objects stored according to the data representation scheme using the multi-part names. Such an application may also include a second engine for constructing visual representations of such workflows, and the second engine may also be configured to store within or retrieve from the data representation scheme the data objects, i.e., using the multi-part names. Preferably, such a computer application is instantiated in a hosted environment accessible by a number of users, e.g., via the Internet.
Still another embodiment provides a computer-implemented method wherein values of fields common to two or more user-specific variants of a data management process are stored in a shared base table; and values of fields that are not necessarily common to the two or more user-specific variants of the data management process arc stored in a shared spill-over table. A common name referencing scheme may be employed to access values stored in either the shared base table or the shared spill-over table. Thus, such a process may be instantiated in a computer application hosted at a computer resource (e.g., a server) accessible through the Internet. The storing processes may be accomplished by soliciting the values to be stored through visual interfaces that have an associated handler application (e.g., a form handler) that references data objects to which the values pertain through the common naming scheme. This common naming scheme may involve the use of multi-part names.